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PROCEDE DB GENERATION D'TOT MODELS DE PERFORMANCE A 
PARTIR D'UN MODELE FONCTIONNEL 

DESCRIPTION 

Domaine t-.*»-Ghiiicme 

L' invention se situe dans le domaine de I'^tude 
des performances par simulation d'un syst^me, tel que 
par exemple un systeme de tel€communication comportant 
une pluralite de composants materials et logiciels 
repartis et qui coopgrent pour fournir un service a un 
ou plusieurs utilisateurs . 

L' invention concerne plus specif iquement un 
proc6dS de generation d'un inodele de performance a 
partir d'un modele fonctionnel d'un tel systeme. 



Tafcat de la fceGhn lmie anterieure 

Lors de la realisation puis du deploiement d'un 
systeme, il faut s' assurer qu'il possdde les capacites 
fonctionnelles attendues, mais aussi qu'il tiendra la 
charge dans les conditions d' exploitation. Si les 
performances chutent, il peut meme arriver que le 
systeme ne remplisse plus les services prevus- Une 
etude de performance a pour premier object if de prSvoir 
les phenomenes d' ecroulement du systdme afin d'^viter 
25 tout dysf onctionnement . 

L.' etude de performance permet de connaitre 
d'une fa<?on precise la repartition des ressources du 
systeme et d' identifier ainsi les eventuels goulots 
d'etranglement. Un second objectif est d' ordre 
30 economique. Il s'agit de determiner les configurations 
optimales des ressources, afin de maximiser leur 




efficacite et ainsi d'eviter 1' achat d' equipements 
supplementaires . Le dimensionnement des ressources 
consiste a determiner les parametres quantitatifs 
necessaires pour la qualite de service desiree tels que 
5 par example la taille des tampons, le nombre de 
serveurs, la repartition des entites de traitement sur 
les differentes machines, etc. 

Une etude de performance s'effectue soit sur un 
modele, soit sur le systeme reel par des mesures . 

10 Lorsque c'est sur un modele, on peut generalement 
observer deux types de comportement du systeme etudie, 
le comportement transitoire et le comportement 
stationnaire . Le premier porte sur des periodes courtes 
et le second sur des periodes longues . Les approches 

15 les plus sollicitees sont notamment les techniques 
mathematiques, la simulation discrete, et 1' analyse 
basee sur des graphes. 

Les notations pour exprimer les moddles sont 
souvent des types suivants : 

20 - systemes S files d'attente, 
" reseaux de Petri temporises, 

- automates temporises, 

- modeles hierarchiques ou descriptions textuelles dans 
des langages specialises. 

25 L' evaluation des performances depend de la 

technique utilisee qui doit §tre choisie en tenant 
compte des caracteristiques de 1 ' application 
consideree. Les techniques de resolution sont class§es 
en trois categories principales : 

3 0 - la m^thode analytique, 

- les tests r^els, et 




- la simulation. 

La methode analytique fait appel le plus 
souvent a la theorie des systemes a files d'attente, ou 
aux reseaxix de Petri stochastiques - 
5 Les systdmes a files d'attente restent I'un des 

plus puissants formalismes math^matiques permettant 
d' analyser quantitativement une tr^s grande variete de 
systemes. Par exemple, un systeme informatique peut 
etre considere, de maniere trSs abstraite, comme un 

10 ensemble de ressources materielles et logicielles 
(serveurs) utilisees par des taches ou des programmes 
(clients). Les ressources 6tant en nombre limite, les 
programmes vont entrer en concurrence pour I'acces a 
ces ressources, et I'on resout cette concurrence par 

15 des files d'attente. 

Le formalisme des reseaux de Petri repose sur 
une representation graphique qui permet de bien 
comprendre le comportement du systSme. Ce formalisme 
convient notamment aux systSmes dont le comportement 

20 est fortement caract^rise par les aspects de 
concurrence/ de synchronisation, de communication et de 
cooperation. Le systdme peut §tre analyst 
qualitativement (absence d' inter-blocage, sGrete de 
fonctionnement , etc.) . 

25 Un handicap majeur du reseau de Petri reside 

dans 1' explosion du nombre d'etats S examiner lorsque 
la complexite du systeme augmente. 

L'approche analytique, enfin, consiste 

generalement a exprimer le comportement du systeme sous 

30 forme d'un modele mathematique exact aboutissant a des 
formules closes. Le comportement du systeme est alors 



reduit S un ensemble de variables liees entre elles par 
des equations. L'atout principal de cette approche 
analytique reside dans le fait qu'elle ne necessite pas 
d'outil de support sophistiqu§ lors des phases de 
5 model isat ion et de resolution du probleme, ce qui 
convient particulidrement aux phases amont de la 
conception d'une application. Avec cette approche, il 
suffit d'appliquer la formule pour determiner les 
quantites recherchees et surtout pour connaitre 

10 1' influence relative des differents parametres. Cette 
approche, qui requiert couramment de fortes hypotheses 
( independance des evenements, conservativite des 
serveurs, etc.), s'avere praticable pour des systemes a 
1' architecture f onctionnelle relativement simple tels 

15 que par exemple 1' etude des systemes de commutation des 
rgseaux de transport. En outre, la methode analytique 
s'avere bien adaptee ^ 1' etude des «pires cas» de 
comportement du systdme, en faisant des approximations 
simplif icatrices et pessimistes. 

20 Cependant, les systemes logiciels se pretent 

beaucoup moins bien aux methodes analytiques, car ils 
presentent beaucoup de variantes de comportement . En 
effet, le comportement .du systdme d' exploitation depend 
fortement de 1' architecture de la machine, sur laquelle 

25 on ne dispose souvent que de trSs peu d' informations . 
Aussi, les interactions entre les differents processus 
peuvent etre tres complexes et difficiles a 
caracteriser par des lois probabilistes . 

Dans les systemes repartis, des complications 

30 supplSmentaires apparaissent du fait de la cooperation 
entre des systemes heterogenes ou seule une vue 




partielle de I'etat du systetne- est disponible au niveau 
de chaque composant. Dans le cas des services de 
telecommunication, il est Sgalement difficile de 
caract^riser le comportement des clients qui g^ndrent 
5 le trafic des requ§tes. 

A 1 ' oppose de la mSthode analytique , 1 ' approche 
par tests reels consiste, moyennant une infrastructure 
d' observation (sondes), a faire des mesures directement 
sur le systeme reel. L' observation se fait ggn^ralement 

10 soit au niveau logiciel, soit au niveau du systeme 
exploitation, soit aux deixx niveaux en meme temps. 
Cette approche a pour avantage I'obtention de resultats 
rSels, notamment pour la capacite de traitement limite 
du systeme (montee en charge) . 

15 La mesure des performances sur un systeme reel 

n^cessite de disposer d'une implantation complete du 
systeme al tester (materiels et logiciels) , par 
consequent 1' etude ne peut etre menee qu'a posteriori, 
et peut impliquer des achats de materiels codteux. La 

20 realisation d'une sonde pour inspecter le systeme est 
une tache difficile car 1' instrumentation ne doit pas 
perturber de maniSre significative ce que I'on mesure. 
En particulier, La repartition des machines nScessite 
une synchronisation d'horloges satisf aisante . De plus, 

25 toute modification logicielle ou mat^rielle entraine un 
surcout de mise en oeuvre en termes d' interoperability 
et de portabilite, de reconfiguration, et de reglages. 
En outre, les programmes de tests doivent etre 
developpes et eux-memes testes et sont fortement lies 

30 au code reel de 1' application ce qui est d'autant plus 
contraignant que les processus de developpement et de 



6 



mise en exploitation d'une application sont courts. II 
faut done souvent d^velopper en paralldle 1 ' application 
et les programmes de tests, ce qui induit de fortes 
contraintes de synchronisation au niveau de 
1' organisation du developpement . Enfin, les tests rgels 
souffrent d'une limitation qui provient du fait que 
seules des configurations simples peuvent §tre 
considerees. Par exemple, la capacity de traitement est 
evaluee en testant le comportement du systdme lorsque 
des demandes de service arrivent simultanSment . Par 
contre, pour connaxtre 1' Evolution du temps de reponse 
(temps maximum, temps moyen, repartition...), de 
1' occupation des tampons et du taux de pertes, il faut 
generer un trSs grand nombre de requetes pour que les 
r^sultats statistiques des tests soient representatif s . 
D' autre part, il faut aussi generer des flux d'arrivee 
de ces requites selon des scenarii representatif s du 
comportement des utilisateurs . Ces flux sont 
caract^ris^s notamment par le taux d'arrivee moyen et 
le rythme (d^terministe, en rafale, al^atoire sur une 
dur^e, exponent ie 1. ..) . Ces contraintes imposent de 
disposer de plusieurs machines client es, car le nombre 
de processus actifs par CPU est souvent limite a 
quelques centaines . Il faut ggalement pouvoir les 
synchroniser pour que le comportement des utilisateurs 
g^nere soit proche de la r^alit^, ce qui est tr^s 
difficile i. mettre en ceuvre. 

L'approche par simulation semble de loin la 
plus utilisge pour 1' evaluation des performances de 
toutes sortes de systdmes et consiste a model iser le 
comportement du systSme, le plus souvent a I'aide d'un 



10 



systdme a files d'attente ou d'un reseau de Petri, puis 
a experimenter le modele en faisant varier un ensemble 
de parametres correspondant aux differentes 
configurations du systdme. Par exemple, pour des 
systdmes logiciels, les parametres peuvent §tre la 
Vitesse de calcul des processeurs, le d§bit de 
transmission des r^seaux, la politique d' ordonnancement 
des processus, le nombre et la topologie des machines, 
le taux et le rythme d'arrivee des requetes, etc.. La 
simulation est plus aisee a apprehender , et plus 
puissante que la methode analytique- En effet, la 
formulation du modele a simuler ne s'exprime pas sous 
forme d' equations mais de programmes, ce qui permet de; 
construire un modele aussi proche que possible du-. 
15 systSme r^el etudie. Elle est beaucoup moins couteuse^. 
en materiel et en logiciel que 1 ' approche . par tests car;., 
elle exploite un module (lane abstraction, une^ 
representation virtuelle) au lieu d'un systeme reel.-. 
Cette approche fournit un outil puissant pour la 
2 0 prediction des performances depuis la conception du 
systeme S etudier jusqu'S sa realisation. 

Des simulateurs logiciels gen^ralistes sont 
apparus depuis 1980 et on peut citer par exemple QNAP 
[http : /www , hyperf ormix . com] , SIMSCRIPT 
25 [http: /www. caci.com/index_main.shtml] , OPNET 
[http : /www . opnet . com] , et SES/Workench 

[http: /www. hyperf ormix, com] . 

Contrairement aux campagnes de tests, le temps 
d'ex^cutions d'une simulation n'est pas lie aux temps 
reels des traitements de 1' application. Ainsi, 
1' approche par simulation permet de realiser un plus 
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grand nombre de scenarii en faisant simplement varier 
les parametres du modele. La mise au point d'un modele 
permet souvent d'enoncer des conjectures sur le systeme 
considere et de pressentir plus facilement certains 
5 elements de r^ponses au probleme de la performance . Les 
simulations permettront de confirmer ou d'infirmer ces 
conjectures. D'autres elements, tels que la 
distribution du temps de reponse de bout en bout ou du 
taux de perte, sont le plus souvent tres difficiles a 
10 quantifier et seule la simulation permet de les mettre 
en evidence . 

L'approche par simulation se dSroule en quatre 

phases : 

» 1' elaboration du modele de comportement du 

15 systeme : elle commence par la selection des entites du 
systSme (un composant logiciel, un processus, etc.) 
qu'il est judicieux de modeliser, par rapport aux 
object if s precis de 1' etude de performance. 
L' elaboration se poursuit par la description du 

20 f onctionnement de ces entites, ainsi que de leurs 
interactions. Les entites sont choisies en fonction de 
la finesse d^siree des resultats de la simulation, mais 
aussi en fonction des donnees initiales qui peuvent 
etre procur^es . Les parametres sont des 

25 caract^ristiques signif icatives des Elements du systeme 
(par exemple, temps de traitement unitaire d'une entite 
sur un processeur, nombre de serveurs, etc.), qui sont 
susceptibles d' inf luencer les r§sultats de simulation. 
Les modules sont representes generalement soit par des 

30 systemes S files d'attente (QNAP, SIMSCRIPT, 
SES /Workbench) , soit par des automates (OPNET) , soit 
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par des r^seaux de Petri . 

G 1' acquisition des donnees qujantitatives pour 
alimenter les simulations : pour des systemes 
logiciels, ces donnees correspondent notamment aux 
5 temps de traitement des programmes sur les processeurs 
et aux delais de transmission si des acheminements a 
travers des reseaux ont lieu. Elles sont mesurees par 
des tests unitaires. Un test unitaire de traitement, ou 
de d^lai de transmission, correspond respect ivement au 
10 temps d' utilisation du processeur (unite centrale) , ou 
du r^seau quand la ressource est entidrement d6di€e au 
processeur. 

o les simulations et la collecte des resultats 
statistiques : on observe le comportement du systdme en 
15 executant le modele a I'aide d'un simulateur et en 
f aisant varier ses parametres - ; on analyse les 
resultats de chaque simulation et on en d^duit des 
resultats de performance pour les configurations 
choisies . 

20 o validation du modele de simulation : la conf iance que 
I'on peut accorder aux resultats de simulations 
n^cessite une validation du modele. Elle consiste a 
realiser quelques tests rSels representatif s 
soigneusement choisis et Sl confronter ces resultats 

2 5 r^els avec ceux obtenus par simulation. 

De mani^re generale, I'approche par simulation 
constitue un bon conrpromis entre cout de mise en oeuvre 
et valeur des resultats. En f aisant varier divers 
parametres, elle permet d' ^tudier le comportement d'un 

30 systeme ou d'une application sous une grande variete de 
configurations. Ceci sans avoir toute 1 ' infrastructure 
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cible du systeme (materiel et logiciel) et, pour les 
applications, sans en faire le developpement complet . 
Par ailleurs, elle convient parfaitement lorsque I'on 
veut comparer des diff^rentes technologies ou produits, 
5 ainsi que pour dimensionner et optimiser le systeme en 
cours d' elaboration. 

Les principales difficultes de I'approche par 
simulation resident dans la capture du comportement du 
systeme a etudier, I'obtention des mesures 
10 quantitatives unitaires et la connaissance statistique 
du comportement des clients du systeme. En effet, tout 
modele de simulation est une approximation du systeme 
reel; et la fid^lite du modele a la realite depend 
fortement de la finesse des connaissances disponibles 

15 sur le f onctionnement du systeme . Or les systemes 
logiciels sont souvent des produits qui se presentent 
sous forme de « boites noires C est -a -dire de 

programmes executables dont on ne dispose pas des 
specifications. L' introduction d'outils de traces pour 

20 comprendre les mScanismes et les comportements internes 
et pour disposer des mesures unitaires sur tous les 
elements qui composent le systeme dans la modelisation 
est une tache indispensable et delicate. En outre, la 
connaissance du comportement des utilisateurs joue 

25 egalement un role primordial pour alimenter les 
simulations, loi d'arrivee des requetes, repartition 
des scenarii utilisateur, etc. En effet, ces Elements 
ont une incidence non n^gligeable sur la performance du 
systdme, notamment en ce qui concerne les temps de 

30 reponse. Cette connaissance ne peut §tre fournie que 
par des mesures sur un systdme r^el , Or, en general 



tres peu de statistiques sont disponibles a ce sujet. 
De plus, pour de nouvelles applications, une 
modelisation anticipee des profils des utilisateurs est 
necessaire . 

Le passage d'un modele bas6 sur les aspects 
fonctionnels d'un systgme Sl un modele de performance a 
fait I'objet de plusieurs travaux cit^s a titre 
d'exemples ci-apres. 

Timed SDL (TSDL) [F . Bause and P. Buchholz, 
^^Qualitative and Quantitative Analysis of Timed SDL 
Specifications", in N. Gerner, H. G. Hegering, J. 
Savolvod, (Eds.) Springer- Verlag, 1993] implemente une 
forme de systemes de transitions temporises, construits 
a partir d'une specification SDL dans laquelle a chaque 
transition, est attachee une duree exponentielle . II 
n'inclut pas de notions de ressources ou de charge. A 
partir d'une representation intermediaire sous la forme 
d' automate, I'outil effectue des analyses qualitatives 
et quantitatives en utilisant des algorithmes de type 
Markovien . 

DL-net [H. M. Kabutz, ^Analytical performance 
evaluation of concurrent communicating systems using 
SDL and stochastic Petri nets". Doctoral Thesis, 
department of Computer science. University of Cape 
Town, Republic Of south Africa, 1997] transforme un 
modSle SDL appauvri (soumis a de fortes restrictions 
sur les types de donnees) en un modele QPN (Queuing 
Petri Nets) , c'est-S-dire un reseau de Petri muni de 
files d'attente. C'est seulement a ce second niveau que 
sont introduites les informations stochastiques de 
dur§e. Un outil convertit ce module en une chaine de 
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Markov qui est ensuite resolue. La semantique de la 
description SDL originale peut §tre diff6rente de celle 
de SDLnet, mais des solutions pragmatiques acceptables 
ont ^te propos^es, du point de vue des auteurs de cette 

5 approche . 

SPECS (SDL Performance Evaluation of Concurrent 
Systems) [Butow M., Mestern M. , Schapiro C. , Kritzinger 
P, S., «Performance Modeling from Formal Specifications 
», FORTE-PST y' 96, Kaiserslautern, Germany, October 

10 1996] permet de modeliser les ressources (les machines) 
par des blocs SDL et les taches s' executant sur une 
machine par des processus a 1' inter ieur d'un meme bloc. 
Les processus dans des blocs differents s'executent de 
maniere concurrente, alors que les processus du meme 

15 bloc s'executent dans un mode multitache . Des delais de 
canaux et des caracteristiques de fiabilitS peuvent 
etre ajout^s. Le modele s' execute sur une machine 
virtuelle qui est d6riv§e du module SDL. 

SPEET (SDL Performance Evaluation Tool) [M. 

20 Steppler, M. Lott, '^SPEET — SDL Performance Evaluation 
Tool", in A. Cavalli, A- Sarma (Ed.), SDL' 97 - Time for 
Testing, Proceeding of the 8^^ SDL Forum, Elsevier, 
19 97.] a pour object if principal 1' analyse de 
performances de systemes specifies en SDL s' executant 

25 dans un environnement temps-reel. Les systemes peuvent 
etre simulSs ou executes sur des emulateurs de 
materiels existants (Intel®, Motorola® et Siemens®) . 
lis sont stimules par des generateurs de trafics et 
sont interconnectes par des liens de transmission 

30 correspondant Sl des canaux physiques. Les utilisateurs 
peuvent d^finir facilement des sondes a I'interieur de 



13 



la description formelle et introduire des indications 
de charge . 

Les approches de [E. Heck, '^Performance 
Evaluation of Formally Specified Systems — the 
5 integration of SDL with HIT", doctoral Thesis, 
University of Dortmund, Krehl Verlag, 1996.] et de 
[Martins J - , «A system Engineering Methodology 
Integrating performance evaluation and Formal 
Specification », PhD Thesis, I'Ecole polytechnique 

10 federale de Lausanne, Avril 1996] introduisent un cadre 
conceptual (HIT) visant une synthase des techniques de 
description formelle et d' evaluation de performance ou 
les proprietes issues de ces deux mondes seraient 
pr^serv^es. Un outil transforme un modele SDL en un 

15 module HIT poss^dant ' une structure hierarchique 
pertinente pour I'Stude de performances, Une traduction 
(manuelle pour 1' instant) a Sgalement Ste proposee vers 
un moddle OPNET, ce qui permet de b§ngf icier de 
simulateurs performants. 

20 QUEST [M. Diefenbruch, "Fonctional and 

Quantitative Verification of Time-and resource Extended 
SDL Systems with Model -checking in : K Irmscher, 

(Ed.), Proceeding of Messung, Modellierung und 
Bewertung van Rechen-und Kommunikationssyste , nen, 

25 Freiberg, Germany, VDE-Verlag, 1997] est base sur un 
langage, QSDL (Queueing SDL), qui est' une extension du 
langage SDL. En ajoutant des annotations indiquant les 
machines qui fournissent des services, des disciplines 
de service, la gestion des files d'attente dans le 

30 modele SDL, le modele QSDL permet d'evaluer par 
simulation la performance du syst^me correspondant 




specif ie en SDL- II permet ggalement de valider et de 
verifier un systeme SDL temporise par model checking, 

DO- IT Toolbox [A. Mitschele-Thiel and B. 
MUlier-Clostermann, «Performance Engineering of SDIJMSC 
5 systems», Journal on Computer Networks and ISDN 
Systems, Elsevier, 1998] effectue 1' Evaluation de 
performance de syst^mes specifics en MSG et en SDL. Son 
originalite est de partir des MSG qui sont disponibles 
tres tot dans le cycle de vie, en y ajoutant des 
10 annotations de charge et precisant les ressources 
disponibles pour des executions specif iques du systeme. 
II fournit une technique simple d' evaluation de 
performance pour 1' analyse de goulots d' etranglement et 
1' optimisation d' implementations, a partir d'hypotheses 
15 de temps de service deterministes . 

EaSy-Sim [C. Schaffer and R. Raschhofer, A. 
Simma, ''EaSy-Sim A Tool Environement for the design of 
Comnplex, Real-Time systems" , Proceeding International 
Conference on computer Aided Systemns technologies, 
20 Innsbruck, Springer- Verlag, 1995] est un couplage entre 
1' environnement GEODE pour SDL et le simulateur 
SES/Workbench. L' environnement SDL est utilisS pour la 
verification et la validation f onctionnelle, alors que 
SES/Workbench modelise la partie non f onctionnelle pour 
25 evaluer la performance. Le couplage est implemente par 
des echanges de messages entre le code executable de 
1' application obtenu par GEODE et le simulateur 
SES/Workbench. Get outil peut s'appliquer a une 
specification MSG dans lequel des exigences de temps de 
30 reponse sont ajoutees pour des systemes temps reel [G . 
Schaffer ^'MSG/RT: A Real-Time extension to Message 
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Sequence Charts (MSG) , Internal Report TR 140-96, 
Institut fur Systemwissenschaf ten, Johannes kepler 
universitat Linz, 1996] . 

EDT (Estelle Developement Tool) [M, Hendaz, « 
Annotation Dynamique pour Evaluation de Performance des 
systemes specif i€s en Estelle », these* doctorat a 
I'Universite Paris 6, 1996.] est un ensemble d'outils 
bases sur le langage Estelle. Le traducteur transforme 
un modele Estelle en un modele intermediaire , annote de 
fa<?on a assigner des temps d' executions non nuls aux 
transitions. Les temps peuvent avoir differentes 
distributions. Le simulateur/debogueur (Edb) , base sur 
le modele semantique defini dans la norme Estelle, 
comporte un jeu de fonctions speciales permettant des 
simulations interactives et aleatoires dans le cadre de 
1' evaluation de performance. 

Configuration Planner [H. M. El-Sayed, D. 
Cam.eron and C M. Woodside, ''A utomated performance 
modeling from scenarios and SDL design of distributed 
systems '\ proceeding of International Symposium on 
Software Engineering for Parallel and Distributed 
Systems (PDSE'98), Kyoto, April 1998] est une approche 
visant, pour des syst§mes temps rSel « temps mou » et « 
temps dur », a transformer de mani^re automat ique un 
modele fonctionnel specifie en MSC en un moddle de 
performance LQN ( Layer edQueueing Network) . La 
simulation des modeles LQN permet d'optimiser, selon le 
critere du temps de reponse, la repartition et 
1 ' ordonnancement des taches sur 1 ' ensemble des 
ressources (les machines) du systeme, Dans ce module la 
contrainte de m^moire est ignor^e. 
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SPEED (Software Performance Engineering Early 
Design) [C, U. Smith and L. G. Williamns, Performance 
Engineering Evaluation of Obj ectOriented Systems with 
SPE-ED", Computer Performnance Evaluation Modelling 
5 Techniques and Tools, no. 1245, Springer -Verlag, 
Berlin, 1997] est un outil permettant d'^valuer 
1' architecture et des solutions alternatives pour la 
conception des systdmes a objets. La specification 
fonctionnelle du systeme est sous forme des diagrammes 

10 de sequences representant des traces d' executions 
(scenarios) . L' outil transforme le modele de 
specification en un modele de performance represents 
par un systeme a files d'attente. Une combinaison 
d' analyse et de simulation permet d' identifier des 

15 problemes de performance potentiels, comme les 
phSnomenes de goulot d' etranglement . 

TLC (Trace-Based Load Characterization) est une 
approche travaillant sur des traces d' executions du 
systeme / qui servent de base a la construction d'un 

20 modele de performance en couches (LQN, ou Layered 
Queuing Network) . Les traces - Message Sequence Charts 
— sent obtenues par simulation d'un moddle SDL, mais 
doivent etre annotSes afin d'expliciter les dependances 
causales qui existent entre les differentes actions 

25 realisees. Par une analyse des Svdnements dStailles de 
la simulation, les annotations des traces sont 
produites selon un principe de marquage incremental, 
qui s'apparente a la technique de coloration du sang 
utilisee en radiographie, 1 ' angiogramme . Une fois ces 

30 chainages causaux etablis, des schemas de 
communication, classiques dans les systemes logiciels. 
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sont identifies, en pratique, chaque message se voit 
attribuer un type, qui peut etre « RPC » (appel de 
procedure distante) , « Forward » (RPC propage a un 
tiers) , « Reply » (riponse a un RPC) , ou « Async » 
5 (emission asynchrone d'un message) . Sur la base de 
cette classification, un modele L.QN est produit 
automat iquement, parametre puis analyse sur le plan des 
performances. Le modele LQN est une specialisation du 
modele classique a files d'attente, adapte a la 
10 description d' architectures logicielles 

traditionnelles, telles que les systemes client- 
serveur . 

Inconvenient des teclmiques anterieures 

15 Les approches de I'art anterieur citees ci- 

dessus consistent soit a effectuer des analyses 
directement sur un modele, soit a simuler un module 
aved un simulateur specif ique. 

Dans le premier cas, les hypotheses de Markov 

20 sont omnipresent es * Elles peuvent ^ventuellement §tre 
verifiees sur des systdmes simples. Cependant, elles ne 
s'appliquent generalement plus dans le cas de systSmes 
complexes a I'interieur desquels de nombreuses 
interactions ont lieu. Faire I'hypothese de Markov 

25 revient alors a considerer une approximation assez 
grossiere du systeme reel, faute de mieux. Quant au 
second cas, la plupart des approches introduisent des 
annotations temporelles a I'interieur du modele 
fonctionnel. Le modele de performance qui en resulte 

30 comporte generalement beaucoup trop de details d'ordre 
fonctionnel/ sans pertinence du point de vue des 



18 



performances, qui oberent I'efficacite des programmes 
de simulation. II faut bien garder a 1' esprit qu'un 
module fonctionnel et un modele de performance ont des 
objectifs fondamentalement differents : du point de vue 
5 performance, on suppose que le systSme fonctionne 
correctement et par consequent, les details de 
f onctionnement (1' ensemble des proprietes logiques) 
n'importent pas, seules comptent la duree pendant 
laquelle une tache detient le CPU et la politique 

10 d' ordonnancement qui gere les taches simultanees- De 
meme, on ne considdre pas les cas marginaux, qui se 
produisent rarement et dont 1 * influence sera 
negligeable statistiquement . Or, ces cas peuvent etre 
nombreux et leur module fonctionnel peut §tre tres 

15 complexe . 

La dernidre approche TLC seduit par le fait 
qu'elle considere un ensemble fini de scenarios, plutot 
qu'une description complete du systerae. Toutefois, le 
modele de files d'attente en couches qui est vise (LQN) 

20 introduit des concepts de haut niveau qui, dans le but 
de favoriser la comprehension du systdme par I'humain, 
s'avdrent a la fois rigides et artificiels vis-a-vis de 
1' analyse des performances, et restrictifs en termes 
d' expressivity . 

25 Enfin, 1' approche TLC cherche a automatiser 

1' identification des liens de causalite entre les 
differents evenements d'un scenario, ce qui nous semble 
trds delicat dans le cas general. En effet, la reaction 
d'un systeme a un stimulus, bien souvent, n'est pas 

30 conditionnee que par ce stimulus, mais egalement par 
I'etat interne du processus ; or, 1' approche TLC 




s' attache S cerner essentiellement les facteurs 
declenchants de type stimulus externe (messages) . En 
fait, la difficulte consiste a exprimer sur les 
scenarios toute 1 ' information de causalite necessaire & 
5 la simulation de performance, tout en parvenant a faire 
abstraction des details fonctionnels du syst&me^. Comme 
nous le decrivons dans la suite, notre approche face ^ 
ce probleme est plus pragmatique, 1 ' identification des 
liens precis de causalite, tres difficile pour une 

10 machine, se revele en general assez naturelle pour le 
concepteur humain. Aussi est-il preferable de mettre a 
contribution le savoir-faire et 1' intuition de ce 
dernier, dans la mesure ou il semble le plus apte a 
fournir le bon niveau d' inf oirmation ♦ 

15 Le but de 1' invention - est de pallier les 

• insuf f isances des systemes de I'art anterieur decrit 
ci-dessus au moyen d'un precede adapte aux plates- 
formes de services, dont le resultat principal est la 
production automatique d'un modele de performance, ^ 

20 partir d'un modele fonctionnel du systeme etudi^. Le 
modele de performance gen^r^ est d€di€ aux simulateurs 
logiciels du rnarch^ bases sur les systemes de files 
d'attente. Le modele fonctionnel s'exprime sous forme 
de diagrammes de sequences assortis de donn§es 

25 temporelles. Les diagrammes de sequence peuvent etre 
derives d'une modelisation dynamique et complete du 
systeme faite en SDL ou en UML, 

Expose de 1^ invention 
■30 Le precede selon 1' invention comporte les 

Stapes suivantes : 




- Rgpartir les requetes representatives du 
systeme en un nombre fini de groupes et identifier, 
pour chaque groupe de requetes, le flot d' execution 
correspondant , la repartition desdites requetes Stant 
5 determinee par le service invoqu^ et par les 
caract^ristiques du comport erne nt propre du client, et 
le flat d' execution pour chaque groupe de requetes 
correspond a 1 ' enchainement d' executions d'entites 
logicielles, en sequence et/ou en parallele, induit par 

10 une requete du groupe . 

Formaliser les flots d' executions S 
I'aide d'une notation permettant de mettre en evidence, 
d'une part, les relations causales entre les 
differentes entitSs logicielles du systdme impliquees 

15 dans les flots d' execution, et d' autre part, les 
informations caract^risant la consommation des 
ressources du systeme, telles que la duree d' occupation 
de CPU lorsqu'une entite logicielle est active. 

Elaborer un module interm^diaire 

20 comportant en plus des flots d' execution formalises, 
une specification de ressources d^crivant les materiels 
physiques du systeme et une specification de 
1 ' environnement representant le comportement des 
utilisateurs . 

25 - Automatiser la transformation du modele 

intermediaire elabore en un modele de performance. 

Pref erentiellement , le modele de performance 
derive du modele intermediaire elabor^ est d€die aux 
simulateurs logiciels pre-existant utilisant des 

30 techniques de rSseaux de files d'attente. 




Selon' une caractSristique de 1' invention, la 
repartition des requites du systeme en un nombre fini 
de groupes de requetes est determinee par le service 
invoque (sa nature) , et par les caracteristiques du 
5 comport ement propre du client qui influencent la 
maniere dont se realise le service invoque. Le flot 
d' execution pour chaque groupe de requetes est 
determine par 1 ' enchainement d' executions d'entit^s 
logicielles, en sequence et/ou en parallele, induit par 
10 une requete du groupe- 

Selon 1' invention, la topologie du modele a 
files d'attente derivee de la transformation est 
entierement determinee par les flots d' execution 
correspondant aux groupes de requetes. 
15 Selon 1 'invention, la derivation d'un modele de 

performance dedie un simulateur pre-existant base sur 
des techniques des reseaux de files d'attente est 
automatisable par adaptation des regies de 
correspondance proposees* 
20 Selon un mode de realisation, le formalisme des 

phases est realise a I'aide d'une extension du 
formalisme MSG (Message Sequence Charts) , et la 
formalisation du graphe des phases et des flots 
d' execution d'un service S I'aide du formalisme HMSC 
25 (High level Message Sequence Charts) est representee 
sous la forme d'un arbre comportant : 

~ une pluralite de noeuds representant les 
phases const ituant le service ; 

- au moins un arc oriente menant d'un noeud 
3 0 a un autre representant 1 ' enchalnement en sequence de 
deux phases ; 




L'arbre de f ormalisation peut comporter en 

outre : 

- au moins un ncEud suivi de plusieurs arcs 
orientSs en parallele, 
5 - au moins un noeud suivi de plusieurs arcs 

orientes en fonction du choix de la phase suivante 
dependant soit d'une condition externe au systeme (liee 
par exemple a una caracteristique du client) , soit 
d'une condition interne liee a I'etat courant du 
10 systeme . 

Ainsi, le modele intermediaire elabore 
comporte les flots d' execution formalises, associes a 
des donnSes temporelles caracterisant le comportement 
d'entites logicielles et leurs interactions, au moins 

15 une specification des ressources decrivant , les 
raat^riels physiques, et au moins une specification 
d' environnement -represent ant le comportement des 
utilisateurs . 

Un avantage par rapport au module LQN reside 

20 dans la disponibilite sur le marche de plusieurs 
ateliers de simulation industriels, Sl la maturite et a 
la puissance eprouvees . Des outils comme QNAP ou 
SES/Workbench proposent des f onctionnalites d' analyse 
avancees permettant de modeliser une tres grande 

25 variete de systemes complexes, ainsi que la possibilite 
de configurer tres finement le module, par exemple, les 
politiques d' ordonnancement des taches peuvent etre 
redefinies de fagon algorithmique , si aucune ne s'avere 
suffisamment realiste parmi les politiques prSd^finies. 




Breve description des dessins 

D'autres caract^ristiques et avantages de 
1' invention ressortiront de la description qui va 
5 suivre, prise S titre d'exemple non limitatif en 
reference axxK figures annex§es dans lesquelles : 

- la figure 1 illustre schetnatiquement le 
precede selon 1' invention / 

- la figure 2 illustre schematiquement un 
10 modele intermediaire defini par le precede selon 

1' invention ; 

la figure 3 illustre schematiquement 
1 ' association des differents elements du moddle 
intermediaire et des primitives du simulateur 
15 SES/Workbench bas^ sur des systSmes a files d'attente ; 

les figures 4a a 4h illustrent 
schematiquement les regies de correspondance entre les 
evenem.ents annot^s caracterisant le comportement 
d'entites logicielles et des primitives du simulateur 
20 SES ; 

- la figure 5 illustre schematiquement un 
sous-modSle SES derivS d'un flot d' execution formalise 
en appliquant des regies de correspondance illustrees 
dans les figures 4a a 4h ; 

25 - la figure 6 represente un sous-modele SES 

de 1 ' architecture globale du systeme obtenu en 
appliquant des regies de correspondance illustrees dans 
la figure 3 / 

la figure 7 illustre schematiquement 
30 I'arbre des phases representant les diff^rentes Stapes 
pour la realisation d'un service Audio-conference selon 
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le precede de 1' invention ; 

- les figures 8 a 10 repr^sentent les flots 
d' execution extraits de I'arbre des phases pour le 
service Audio -conference ; 

5 - les figures 11 ^ 20 representent des 

schemas de f ormalisations des phases du comport ement du 
service fourni ; 

La figure 21 represente la declaration 
des ressources, les flots d' executions et le sous- 
10 modele de 1 ' architecture globale d'une plate- forme 
d' audioconf erence dans le modele SES ; 

- La figure 22 represente un sous-moddle 
SES de 1' architecture globale de la plate-forme 
d ' audio - conference / 

15 - Les figures 23 i. 25 representent les 

sous-moddles SES derives des differents flots 

d' execution formalises en appliquant des regies de 
correspondance illustr^es dans les figures 4a a 4h- 

20 Expose detaille de modes de realisation particuliers 

Pour modeliser un systeme etudie, le precede 
selon 1' invention utilise les syst^mes ^ files 
d'attente. Ce choix est lie au fait que les simulateurs 
de performances les plus avances du marche exploitent 

25 pour la plupart le modele des reseaux de files 
d'attente. Ces ateliers font preuve d'une maturite 
notoire, tant sur le plan de la richesse des 
fonctionnalites, que de la qualite de 1' analyse et de 
la robustesse • 

30 Rappelons qu'un modele d'un systSme S files 

d'attente se concentre sur les aspects qui ont un effet 
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direct ou indirect sur la cons ommat ion des ressources 
du systdme (processeurs et Tu^mdires des machines, bande 
passant e des rSseaux de transport) , 

Le proc6d6 selon 1' invention permet de 
5 modeliser essentiellement : 

© la repartition des entit^s .logicielles 
dont la cooperation realise le service sur les 
differentes machines; 

o les interactions, ou relations de 
10 causalite, qui existent entre ces entites logicielles, 

o les dur^es de traitement unitaire, 
o les politiques d' ordonnancement des 
taches concurrentes, 

o la capacite des reseaux sous-jacents 
15 (caracterisee par les delais de transmission et la 
politique de rout age) , 

© le comportement des utilisateurs 
caracterise par le debit d'arrivge des requetes, et par 
la distribution de la duree qui s^pare deux arrivees 

20 consecutives . 

Un systdme logiciel r^parti se compose 
ggn^ralement d'un ensemble d'entit€s logicielles 
(processus, composants, etc.) s' executant sur un 
ensemble de machines connectees par des reseaux de 

25 transport. Ce type de systeme se modelise en associant 
un serveur muni d'une file d'attente a chaque couple 
compose d'une entite logicielle et d' une machine sur 
laquelle s' execute 1' entite. Deux entites logicielles 
hebergees sur une meme machine sont considerees comme 

30 deux serveurs distincts. Pour chaque serveur ainsi 
dSfini, son service et sa file d'attente correspondent 



respect ivement a 1' execution de 1' entity at a la 
memoire de la machine • 

Les clients sont les requetes envoyees par les 
utilisateurs invoquant des services fournis par le 
5 syst^me. Quant a la topologie du systdme a files 
d'attente, elle est determinee entiSrement par les 
traces d' execution. En effet I'arrivee d'une requite 
dans le systSme provoque 1' execution d' actions sur les 
serveurs . Ces actions peuvent evoluer simultanement (en 

10 parallele) ou se synchroniser en sequence. Chaque trace 
d' execution est ainsi representee par une arborescence 
de serveurs. En definitive, la topologie globale du 
reseau de files d'attente est telle que toutes les 
traces d' execution sont couvertes. 

15 Avant de procfider §l la simulation du modele, 

cslui-ci doit encore etre complete d'un models 
d' environnement et d'un modele de ressources. Le 
premier caract^rise le comportement des utilisateurs, 
en termes de debit et de distribution statistique des 

20 temps d' inter- arrivees . Le second precise la duree 
d' execution de chaque entity lorsque la machine lui est 
entidrement dediSe (tests unitaires) , les delais de 
transmission caracterisant la capacite des reseaux et 
la politique d' ordonnancement des traitements 

25 concurrents. Ces donnees peuvent Stre int^gr^es dans le 
modele fonctionnel du systeme. La simulation consiste a 
injecter un tres grand nombre de requetes dans le 
modele. On optimise 1 ' utilisation des ressources du 
systeme en cherchant une bonne configuration (ou 

30 parametrage) des diff brents elements du moddle. La 
qualite de la configuration globale s'evalue en 



etudiant par simulation son impact sur la charge des 
serveurs, sur le taux d' occupation des tampons, et sur 
des quantites caracterisant la qualite de service: les 
temps de reponse d'un composant particulier ou du 
5 systeme (de bout en bout) , la capacite de traitement 
maximum (volum^trie) , etc. 

Pour des logiciels repartis quelconques, 
1' identification des interactions ou relations de 
causalite entre les entitSs logicielles peut etre trds 

10 complexe, voire impossible- En fait, la demarche 
proposee par 1' invention est applicable aux systemes 
dont on peut raisonnablement resumer le comportement 
par un ensemble restreint de scenarios d' execution. 
Idealement, les scenarios choisis evolueront 

15 independamment les uns des autres . Neanmoins, les 
systemes impliquant des dependances entre. scenarios 
sont acceptables • (en cas d' interaction entre devix 
clients par exemple) , tant que ces d^pendances 
demeurent clairement exprimables par le concepteur. 

20 Les plates-formes de seirvices constituent en ce 

sens un champ d' application concret pour la mise en 
ceuvre de 1' invention. En effet, 1 ' utilisation de ce 
type de plate -forme peut souvent etre caract§risee par 
un nombre raisonnable de scenarios, qui correspondent 

25 aux diff brents cas d' utilisation de la plate-forme 
(autrement dit, au traitement des differentes requetes 
emises par les utilisateurs lors de 1' invocation des 
services) , et qui dependent faiblement les uns des 
autres . 

3 0 Comme cela est illustre schematiquement par la 

figure 1, le veritable point de depart, pour la 




generation d'un modele de performance a files 
d'attente, consiste S r§partir les requetes 
representatives du systdme en un nombre fini de groupes 
de requetes et a identifier (etape 2), pour chaque 
5 groupe de requetes, le flot d' execution correspondant . 
Ceci permet de determiner la topologie globale du 
systeme a files d'attente afin que s'y ref latent toutes 
les traces d' execution induites par des requetes 
representatives. Les requetes representatives sont 

10 celles dent la frequence d' emission dans le systeme est 
significative. La repartition de ces requetes est 
determinee d'une part par le service invoque ; et 
d' autre part, par les caracteristiques du comportement 
propre du client qui influencent la manidre dont se 

15 realise le service invoqu§ (voir dans I'exemple 
d'Audioconference) . Quant au flot d' execution pour 
chaque groupe de requetes, il correspond a 
1 ' enchalnement d' executions d'entites logicielles, en 
sequence et/ou en parallSle, induit par une requ§te du 

20 groupe. 

Repartition des requetes et identification des flots 
d' execution : 

Pour la premiere ^tape (n*'2 sur la figure 1) , 
2 5 chaque seirvice du systeme est represents sous la forme 
d'un arbre aux caracteristiques suivantes : 

les noeuds de 1' arbre representent les 
phases constituant le service. Un noeud particulier, le 
noeud initial, correspond a la phase qui initie le 
30 service ; 

- un arc orient e menant d'un noeud ^ un 



autre repr^sente 1 ' enchainenient en sequence de deux 
phases 

- lorsque plusieurs arcs sont issus d'un 
tn§me noeud N, cela correspond soit a 1' execution en 
5 parallele de toutes les phases suivantes, soit a un 
choix de 1' execution d'une et une seule des phases 
suivantes. Dans ce dernier cas, le choix de la phase 
suivante est liS & une condition portant soit sur une 
propriete liee au comportement de 1 'utilisateur, la 
10 condition est alors dite externe, soit sur I'etat 
courant du systeme, dans ce cas, la condition est dite 
interne . 

Les requetes sont naturellement regroupees sur 
la base des choix effectues au niveau des conditions- 

15 externes- Les f lots d' execution correspondants peuvent 
etre extraits de I'arbre global en parcourant celui-ci 
a partir du noeud initial-, et en ne retenant qu'un seul 
successeur a chaque condition externe rencontr^e . Par 
consequent, un flot d' execution est un sous-arbre de 

20 I'arbre global caracterise par la transformation 
systematique de tout alternative externe parmi N 
successeurs en un enchainement en sequence vers un seul 
de ces successeurs- Lors du parcours, tout autre aspect 
structurel de 1 ' arbre est en revanche conserve 

25 (enchainement en sequence vers un noeud simple, 
enchainement parallelism vers plusieurs noeuds en 
simultane, enchainement conditionne par I'etat interne 
du systeme) . Les figures 8 a 10 illustrent les flots 
d' execution extraits de 1' arbre des phases (figure 7) 

30 dans I'exemple du service Audio-conference. 




Formalisation des flots execution 

L'^tape 4 du precede (figure 1) consiste a 
formaliser les flots d' execution a I'aide d'une 
notation permettant de mettre en Evidence les 
interactions entre les differentes entites logicielles 
impliquees dans les flots d' execution et les 
informations caracterisant la consommation des 
res sources du systeme . 

Dans le mode de realisation decrit, cette 
formalisation est basee sur les Message Sequence Charts 
(MSC) . Cependant, d'autres formalismes de diagrammes de 
sequence pourraient etre utilises. La coherence d'un 
MSC est optimale si le diagramme est produit en tant 
que trace d' execution du systeme. En phase de 
conception, une specification executable du systSme 
peut-etre produite en langage SDL, qui se trouve §tre 
un formalisme etroitement lie aux MSC sur le plan de la 
semantique. En pratique, tous les outils SDL sent 
capables de produire des traces de simulation dans le 
format MSC. Ces mSmes outils off rent en outre la 
possibility d'editer manuellement de tels diagrammes, 
et c'est ainsi que I'on pourra procgder a defaut 
d' exploiter la simulation d'un module SDL. 

Les evenements qui apparaissent sur un 
diagramme MSC portent essentiellement sur des aspects 
fonctionnels : emission ou reception de message, 
action, armement ou expiration de temporisation, etc. 
En realite, ce niveau d' information est non pertinent 
ou insuffisant pour un module de performance : par 
exemple, le nom des messages n'a pas d' importance . Pour 



rendre possible la production d'un modele de 
performance, il est necessaire de preciser, pour les 
§v6nements concernes : 

la duree d' occupation du processeur 
5 engendree par le traitetnent de 1 ' evenement . 

les conditions d' enchalnement , qui 
specif ient dans quelle cnesure 1' execution d'un flot 
peut se poursuivre . Une condition d' enchainement porte 
soit sur I'attente de 1' expiration d'un d^lai, soit sur 

10 la validity d'une expression booleenne. Elle peut Stre 
vue comme une porte faisant obstacle a la poursuite de 
1' execution, et les composantes de la condition comme 
les cles qui doivent etre rassemblees pour franchir 
cette porte. Ces cles doivent etre definies par le 

15 concepteur et servent a indiquer la realisation de 
certains faits qui contribuent alors ^ la validation de 
la condition d' enchainement . Ces cles seront 
typiquement representees par des indicateurs boolSens 
tels que par 

20 exempleutilisateur_connecte . nb_max_tentatives_atteint , 
etc . 

la publication de faits, qpai peuvent 
avoir un effet d^clencheur sur le deblocage d'autres 
flots. Le traitement d'un Svgnement peut contribuer a 

25 remplir les conditions d' enchainement qui bloquent 
1' execution d'une autre entite. Dans I'analogie avec 
les cles, cela correspondrait a I'acte de fournir 
certaines cles aux autres entites du systeme, de 
« publier des faits ». 

30 - la terminaison eventuelle d'une des 

branches paralleles dans un flot d' execution. 




Ces quatre types d' information sont 
indispensables au module de performance, pour calculer 
le temps de reponse, la repartition de charge des 
machines, la longueur des tampons, etc- Le precede 
5 definit cinq clauses correspondantes (dont deux pour 
les conditions d' enchainement) , qui constituent ainsi 
1' extension de la notation pour formaliser les flots 
d' execution : EXEC (occupation du processeur) , EXPECT 
(condition d' enchaxnement sur une expression 

10 booleenne) , DELAY (condition d' enchalnement . sur 
I'ecouleraent du temps), PUBLISH (publication de faits) , 
et END (terminaison de la branche du flot) . Les figures 
11 a 20 illustrent les flots d' execution formalises 
dans I'exemple d'un modele fonctionnel du service 

15 Audioconf erence . 

Elaboration du modele Intermedialre 

L'Stape 6 du procedg (figure 1) consiste a 

definir un modele intermedialre destine a permettre le 
20 passage automatique S un modele de performance. Sur la 

figure 2, on voit que ce modele est compose des flots 

d' execution formalises (10) caract^risant le 

comportement d'entites logicielles et leurs 

interactions, d'une specification des ressources (12) 
2 5 decrivant les matiriels physiques, et d'une 

specification d' environnement 14 representant le 

comportement des utilisateurs . 

Le modele .de ressources contient les 

declarations suivantes : 
30 - les machines, la taille des tampons et la 

politique d'ordonnancement des traitements simultanes 




de ces machines ; 

les r^seaux de transport et leurs 
topologies permettant la connexion des machines ; 

les entit§s logicielles (programmes a 
5 unique fil d' execution) , ainsi que leur repartition sur 
les ressources ; 

- les capacites des machines exprimees par 
rapport aux temps de traitement unitaires des taches 

. (formalisees par EXEC) ; 
10 - les capacites des liens de transmission 

exprimees par rapport aux delais de transmission ; 

Dans le modele d' environnement , qui caract arise 
le trafic de requites genere par les utilisateurs , il 
15 faut preciser les donnees suivantes : 

- le debit d'arrivee des requetes ; 

- le rythme d'ax^rivee ; il est caracterise 
entierement par la distribution de la duree s^parant 
deux arrivSes consecutives ; 

20 - les attributs ; ce sont des variables 

propres a chaque recjuete ; ils permettent notamment 
d' identifier les diff^rentes classes de requetes 
determinees par les flots d' execution / d'autres 
variables servent a exprimer les conditions boolSennes 

25 de synchronisation entre des branches paralldles d'un 
mgme flot d' execution. 

la proportion de chaque classe de 
requetes (cette repartition est fournie par des 
observations ou des estimations quant S 1' usage futur 

30 de la plate-forme) 




Transformation automat ique en un modele de 
performanceL' gtape 8 du procede (figure 1) consiste k 
definir des regies de correspondance entre les elements 
du modele intermgdiaire et les primitives d'un 
5 simulateur generaliste base sur des systemes S files 
d'attente. La transformation devient automatique 
lorsqu'on applique ces regies de correspondance. Ces 
dernieres s'appliquent aussi bien a tous les 
simulateurs de cette categorie : tous sont fondes sur 

10 les memes concepts de base, seul le mode de 
representation de ces concepts differe. La coherence de 
la transformation repose sur des regies de semantique 
(non explicitees dans le present document) , qui 
permettent de detecter les specifications erronees 

15 conduisanc 1 des modules de performance incomplets ou 
denues de sens. Nous illustrons ici la demarche dans le 
cas d' utilisation du simulateur SES /Workbench. 

La figure 3 illustre schSmatiquement les regies 
de correspondance entre le moddle intermediaire et des 

2 0 « noeuds » SES /Workbench . En d^signant respectivement 
par R={machine_l, machine_m} et 

F= { f lotExecFormalise_l , f lotExecFormalise_n} 

1' ensemble des machines du systeme declarees dans le 
modele de ressources et 1' ensemble des flots 

25 d' execution formalises des services du systeme : 

- Le modele d' environnement 14 est associe 
a un noeud « source » 20, suivi eventuellement d'un nceud 
« submodel » 22. Ce dernier est utile dans les cas plus 
complexes, par exemple dans le cas de requetes 

30 structurges par sessions ou a plusieurs niveaux ; 

- Le modele de ressources 12 contenant la 




declaration de 1' ensemble R de m machines est associe a 
\in ensemble de m noeuds « service » denotes par un nom 
logique (serveur_j par exemple) , pour tout j ; 

- Chaque f lotExecFormalis6_i 10 est associg 
5 a un noeud « submodel » denote par un nom logique 

(flotExec_i par exemple) pour tout i ; 

- Chaque nceud « submodel » associe au flot 
d' execution formalist est developpe, en faisant les 
correspondances suivantes entre ^venements du flot 

10 d' execution formalise et primitives SES . Les 
differentes associations sont decrites par les figures 
4a a 4h. 

En reference a la figure 4a, la primitive 
« EXEC(t) » est associee a une sequence de deux noeuds : 
15 un nceud « user », suivi d'un ncEud « service 
reference_to Le ncsud user permst ds specifier la 

valeur de t correspondant a la duree d' execution de 
code, tandis que le ncsud « service reference_to » fait 
reference au nceud service declare dans le module qui 
20 correspond la machine hebergeant le processus qui 
effectue le « EXEC(t) ». 

La publication de faits « PUBLISH » est 
associee (figure 4b) Bl un nceud « user » contenant le 
programme C adequat . Ce programme modifie les variables 
25 qui reprSsentent les cles ou faits a publier. 

La fin de branche de flot « END » est associee 
a un noeud « sink » (figure 4c) . 

La primitive « DELAY (t) » est associee a un 
noeud « delay » (figure 4d) et la valeur de t est le 
3 0 .parametre du noeud. 



La condition d' enchaxnement « EXPECT » est 
associee a un nceud « block ou elle s'exprime par une 
expression booleenne c donnee en parametre du noeud 
(figure 4 e) • 

5 L' enchainement en sequence des gvenements est 

represente par un arc entre les nceuds (figure 4f ) . 
Le choix d'un enchainement des Svgnements parrai N 
enchainements possibles est represent^ par N arcs 
partant du noeud ou le choix a lieu. Les conditions 
10 determinant un choix sont specif i€es dans I'arc 
correspondant (figure 4g) . 

Enfin la separation du flot en N branches 
paralleles est representee par un nceud « split » 
(figure 4h) * 

15 La figure 5 illustre la sequence correspondant 

au sous-modele d'un flot d' execution formalise 
completee par un ncfiud « enter » et par un noeud 
<c return » qui representent respectivement 1' entree et 
la sortie du sous-modele. 

20 La figure 6 illustre 1' architecture globale du 

systeme, qui rassemble les sous-modeles flots 
d' execution et le sous-modele d' environnement . 

Example d' application : plate-forme d' Audio-conference 
25 Presentation informelle du service d' audio- 

conference . 

Le service d' Audio -conference permet a un 
nombre determine d'usagers, sur accord prealable, 
chacun de son cote et a une date et heure convenues, de 
30 composer un numero d'appel afin d'etablir une 
communication vers un pont de conference. La 



reservation d'un pont de conference ayant prealablement 
ete effectuee par I'un des participants, qui a precise 
la date, I'heure, la duree et le nonibre de 
participants . 

5 La realisation du service d' §tablissement d'une 

session de conference, offert par la plate- forme 
d' Audio- conference, depend du r51e (de la nature) du 
client qui I'invoque : 

- est-il organisateur de la session ? 
10 - est-il un simple participant ? 

- est-il autorise a participer k la session ? Cette 
classification permet d' identifier les diffgrents types, 
de requetes. Par ailleurs, il se peut qu'un type de 
requete interagisse avec un autre. Par exemple, le 

15 traitement de la requete d'un simple participant a ' une 
session d' Audio-conference est suspendu jusqu'a 
I'arrivee de 1' organisateur de cette session. 

Un r61e particulier est affecte a 
1' Organisateur de la conference. La conference ne peut 

20 commencer avant I'arrivee de 1 ' Organisateur , c'est-a- 
dire que les participants ne peuvent pas §tre connect es 
au pont de conference tant que 1 ' Organisateur est 
absent. La conference est fermee apres raccrochage de 
1' Organisateur, et les participants encore en ligne 

25 seront alors deconnectes du pont de conference. La 
souscription, qui consiste principalement en la 
reservation d'un numero d'accds au pont de conference, 
s'opere par 1 ' intermediaire du fournisseur de service. 
Les donnees sont en consequence recuperees dans la base 

3 0 de donnees- 
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Traitement appel 

Le traitement d' appel se decompose suivant les 



phases suivantes (remarque : on ne s*interesse, pour 
cette etude de cas, qu'^ l»ouverture de conferences, et 
5 non a leur evolution ni a leur cl6ture) : 

1) Un participant compose le numero d'acces sL la 
conference programraSe (numero d'acces au service NAS) . 
Ce numero est compose d'un prefixe de type OZABPQ 
specif ique au service, tandis que le suffixe MCDU est 

10 specif ique a la conference souscrite. Le service 
effectue la traduction du numero d'acces au service en 
numero reel d'accgs au pont de conference (NAC) . 

2) Plusieurs cas sont possibles: 

- Tant que le nombre de participants est inferieur a la 
15 capacite maximale du pont de conference et que 

I'Organisateur n'a pas invoque le sar^/ice, un message 
est emis qui annonce le retard de 1 ' organisateur , puis 
un second invitant a attendre I'ouverture de la 
conference . 

20 Quand I'Organisateur se presente, les 

participants en attente sont alors connect4s au pont de 
conference (ainsi que I'Organisateur) . La conference 
est dite ouverte. 

- Si le nombre de participants deja connectes atteint 
25 le nombre maximal defini par le souscripteur , le 

service rejette 1' appel avec un message de saturation. 

Messages specifiques au service 

Les libelles des messages specifiques au 
30 service sont les suivant s : 

- accueil : "vous avez compose un numero d'accds a une 




conference, veuillez ne pas quitter". 

- saturation : "le numero compose est sature, nous ne 
pouvons donner suite a votre appel"- 

- incident : "suite a un incident, nous ne pouvons 
5 donner suite a votre appel", 

annonce : "votre organisateur n'est pas encore 
connecte..." . 

- attente : "veuillez ne pas quitter, vous serez mis en 
communication avec vos correspondants des ouverture de 

10 la conference..." . 

Donnees 

Les donnees specifiques au service sont : 

- les n^ d'acces au service 

15 - les n^ traduits (le numero r6seau du pont) 

le nombre maximal de participants par pent de 
conference 

- I'etat de la- ressource associee au pont de conference 

- la table des annonces 

20 - les tables d' analyse nationale, Internationale et 
speciale (pour des controles eventuels sur le numero 
appelant) . 

Ces donnees sont de differents types, suivant 
que leur modification se fait ou non par les scripts du 

25 traitement d'appel. Les donnees non modifiables par le 
traitement d'appel sont dans une base de donnees 
appelee ici SDF (Service Data Function) , elles sont 
accessibles en lecture par les scripts du traitement 
d'appel et en ecriture pas des scripts de gestion. Les 

30 . donnees modifiables par le traitement d'appel sont dans 
une base de donnees accessible en lecture et ecriture 




par les scripts du traitement d'appel, cette base de 
donnees doit fournir des performances d'acces plus 
itnportantes . Ce dernier type de donn^e est represents 
ici par le notnbre maximal de participants, et par 
5 I'etat de la ressource. 

Application des etapes du procede 

A partir de la description informelle du 
service, la premiere etape consiste a identifier les 
10 phases elementaires et leur organisation en un arbre de 
phases , 

Tous les comportements des utilisateurs ne sont 
pas pris en compte, seuls sont exprimes les cas 
d' utilisation les plus representatif s . En particulier/ 

15 les raccrochages sont pris en compte en phase de 
conversation et en phase d'attente, cas de raccrochage 
les plus pertinents d'un point de vue utilisateur. 

La figure 7 illustre 1' arbre global des phases 
qui dScrit 1 ' enchainement des diffSrentes phases en 

20 prScisant les alternatives internes ou externes . On 
reconnait les conditions externes au fait que les arcs 
qui en sont issus portent des pourcentages 
statistiques . 

Apres une phase de connexion PI, une 

25 alternative externe permet d' identifier si 

1 ' utilisateur est 1 ' organisateur (P2) ou un simple 
participant (P4) . Si 1 ' utilisateur est un participant, 
une alternative interne {nbParticipants<MAXI } , dont 
1' option depend de 1' execution d'autres scenarios, 

30 identifie si le nombre maximum de participant est 
atteint ou non. Si ce nombre est atteint, une phase 




pour 1' envoi d'un message de saturation est initiee 
(P6) . Si ce nombre maximum n'est pas atteint (P5) , une 
deuxieme alternative interne {organisateurPresent } 
permet d' identifier si 1' organisateur est deja present. 
5 S'il est deja present, le participant est connecte au 
pont (P7, avec en pr^alable un message d'accueil). Si 
1 ' organisateur est absent, un message d'attente est 
emis vers le participant (phase P8) . De cette phase, 
une condition externe (participantPatient } permet de 

10 distinguer le cas ou le participant attend 1 ' arrivee de 
1' organisateur (phase PIO) et entre dans la conference 
(phase P7) a 1' arrivee de 1 ' Organisateur , du cas ou le 
participant est plutot du type "impatient", c'est-a- 
dire qu"il raccroche suite a 1 ' annonce de retard 

15 diffusSe en phase - P9 . Dans ce cas, le nombre de 
participants est diminu^ d'une unite. Encore une fois, 
on suppose que seules les performances des phases liees 
a 1 '^tablissement de la conference nous interessent 
dans cet example, ce qui explique que I'arbre ne 

20 contienne aucune phase liee a 1' evolution ult^rieur de 
la conference. 

Les requ§tes dans I'exemple sont r^parties en 
trois groupes : requetes envoyees par un organisateur ; 
requites envoyees par un simple participant patient ; 

25 et requetes envoyees par un simple participant 
impatient. A partir de I'arbre global des phases, on 
extrait alors les trois flots d' execution 
correspondants en ne gardant qu'une branche de chaque 
alternative externe : 

30 - flot d' execution induit par 1' arrivee de 

1 ' organisateur (figure 8) ; 




flot d' execution induit par I'arriv^e 
d'un simple participant patient (figure 9) ; 

flot d' execution induit par I'arrivee 
d'un simple participant impatient (figure 10) . 

5 

Identification des cles et portes des phases concernees 
La deuxieme etape du proced6 consiste §i 
identifier les cl€s et portes qui influencent le 
comportement d'un cas d' utilisation a partir du 

10 comportement d'un ou plusieurs autres cas 
d' utilisation. Dans le cas du service d' Audio- 
conference, on identifie une cle liee a la presence de 
1 ' organ isateur. La phase P3, executee lors de I'arrivee 
de 1 ' organisateur, inclut la 

15 tSche PUBLISrl (organisateurPresent) . 

Jne telle publication permettra de d^bloquer la 
phase PlO qui inclut une tache 

« EXPECT (organisateurPresent) »• 

La variable nbParticipants est augment^e de 1 

20 lors de la connexion d'un utilisateur (non 
organisateur) , sauf si elle vaut deja sa valeur maximum 
autoris^e (MAXI) . Ce test est represent g par une 
alternative interne dans I'arbre de phases. 



25 Formalisation des phases 

Les figures 11 a 20 representent des schemas de 
formalisation des phases du comportement du service, 
les MSG associes a differentes phases du comportement 
du service seront donnas avec une vue simplifiee sur le 

3 0 nom des signaux. De mSme, tous les ^changes ne sont pas 
indiques afin de ne pas alourdir les schemas. 



Les instances considerees dans ces MSG sont : 
- le SDF (Service Data Function ou base des donnees de 
service) / 

le SCF (Service Control Function ou plate- forme 
5 d' executions des services), 

le SRF (Service Resource Function ou plate -forme 
vocale) et les USER (utilisateurs) . 

Les ^changes de signaux correspondent : 
aux interrogations de la base de donnees : 
10 o appelant (numeroAppel ant ) interroge la base 

sur le numero appelant {P2,P4) ; 
© typeAppelant est la reponse de la base, 
elle peut prendre les valeurs ORGANISATEUR 
(si 1' appelant est 1 ' organisateur) ou 
15 PARTICIPANT (si 1' appelant n'est pas 

1' organisateur) . 
aux echanges de messages vocaux en passant par la 
plate -forme vocale : send_message vers la plate -forme 
vocale, msg_info vers I'utilisateur (P6, P7, P9) . 

2 0 - aux ^changes pour la synchronisation par les 

portes : 

o PUBLISH (organisateurPresent) permettra de 
publier le fait que 1 ' organisateur vient 
de se connecter. 

25 o EXPECT (organisateurPresent) permet le 

blocage de 1' execution de l^entite SCF 
j usqu ' a 1 ' ar r ivee de 1 ' organi sa t eur . 
La figure 11 represente la f ormalisation de la 
phase d' invocation du service. 

3 0 La figure 12 represente la f ormalisation de la 

phase « Identif icationOrganisateur ». 
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La figure 13 represente la f ormalisation de la 
phase « Identif icationParticipant » . 

La figure 14 represente la f ormalisation de la 
phase « OuvertureDeLaConf erence » . 



phase « ConnexionParticipant » , 

La figure 16 represente la f ormalisation de la 
phase « DeconnexionSuiteASaturation » , 

La figure 17 represente la f ormalisation de la 
10 phase » EntreeDansLaConf erence » . 

La figure 18 represente la f ormalisation de la 
phase « AnnonceRetardOrganisateur » . 

La figure 19 represente la f ormalisation de la 
phase ^< AttenteOrganisateur » . 
15 La figure 2 0 represente la f ormalisation de la 

phase « AbandonSurAttente ». 

Modele de performance derive du modele fonctionnel 

La figure 21 represente la vue gSnerale du 
20 modele intermediaire (dans SES/WorldDench) . On y 
trouve : la declaration des ressources, les trois flots 
d' executions et le sous-modele de 1' architecture 
globale de la plate- forme d'Audio-conf erence . Dans cet 
exemple, les processus SDF, SCF et SRF s'executent 
25 chacun sur une machine. 

Une vue interne de 1 ' architecture globale de la 
plate-forme est representee par la figure 22. 

Le noeud initSession initie la creation du 
nombre maximum de sessions simultanees autorisees par 
30 la plate-forme. Le noeud appelsDuneSession genere les 
appels pour chaque session ouverte et le noeud 
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La figure 15 represente la 



formalisation de la 
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interAppOrdre modelise les durees qui separent les 
appels consecutifs d'une session et le rang auquel 
arrive 1' organisateur . Enfin, chaque fin de session, 
^representee par le nceud f ermetureSession d^clenche la 
5 creation d'une nouvelle session representee par le noeud 
creationSession . 

Les Figures 22, .24, et 25 montrent 
respectivement les trois sous-moddles resultant de la 
transformation des flots d' executions de 

10 I'organisateur, d'un participant patient, et d'un 
participant impatient . 




REVENDICATIONS 
1. Precede de generation d'un moddle de 
performance S partir d'un moddle fonctionnel d'un 
systeme comportant une plurality d'entites mat^rielles 
et logicielles reparties cooperant pour fournir un 
service a au moins un utilisateur, caracterise en ce 
qu'il comporte les etapes suivantes : 

- Repartir les requetes representatives du 
systSme en un nombre fini de groupes et identifier, 
pour chaque groupe de requetes, le flot d' execution 
correspondant , la repartition desdites requetes etant 
determinee par le service invoque et par les 
caracteristiques du comportement propre du client, et 
le flot d' execution pour chaque groupe de requetes 
correspond ^ 1 ' enchalnement d' executions d'entites 
logicielles, en sequence et/ou en paralldle, induit par 
une requete du groupe, 

- Formaliser les flots d' execution Sl I'aide 
d'une notation permettant de mettre en Evidence, d'une 
part/ les relations causales entre les diffSrentes 
entites logicielles du systeme impliquSes dans les 
flots d' execution, et d' autre part, les informations 
caracterisant la consommation des ressources du 
systeme, telles que la duree d' occupation de CPU 
lorsqu'une entite logicielle est active. 

Elaborer un modele intermediaire 
comportant en plus des flots d' execution formalises, 
une specification de ressources decrivant les materiels 
physiques du systeme et une specification de 
1' environnement repr^sentant le comportement des 
utilisateurs . 



- Automatiser la transformation du modele 
intermediaire elabore en un modele de performance. 

2. Procede selon la revendication 1, caracteris^ 
en ce que le models de performance derive du module 

5 interm§diaire elabore est dedie aux . simulateurs 
logiciels pr^-existant utilisant des techniques de 
reseaux de files d'attente. 

3. Precede selon la revendication 1, caracteris^ 
en ce que la repartition des requites du systeme en un 

10 nombre fini de groupes de requites est d^terminee par 
le searvice invoquS et par les caracteristiques du 
comportement propre du client qui influencent la 
maniere dont se realise le service invoque . 

4 . Procede selon I'une des revendications 1 a 3, 
15 caracterise en ce que le flot d' execution pour chaque 

groupe de reqiaetes est determine par 1 ' enchaxnement 
d' executions d'entites logicielles, en sequence et/ou 
en parallele, induit par une requete du groupe. 

5. Procede selon la revendication 4, caracterisS 
20 en ce que la topologie du module Sl files d'attente 

derive de la transformation est entierement dStearminee 
par les flots d' execution correspondant aux groupes de 
requites . 

6. Procede selon la revendication 4, caracterise 
25 en ce que la derivation d'un modele de performance 

dedi^ a un simulateur pr^-existant bas^ sur des 
techniques des reseaux de files d'attente est 
automatisable par adaptation des regies de 
correspondance propos^es . 
30 7. Procede selon I'une des revendications 1 a 6, 

caracterise en ce que le formalisme des phases est 



realise a I'aide d'une extension du formalisme MSG 
(Message Sequence Charts) . 

8. Precede selon I'une des revendications 1 a 
7, caractSrise en ce que la f ormalisation du graphe des 

5 phases et des flots d' execution d'un service a I'aide 
du formalisme HMSC (High level Message Sequence Charts) 
est represents sous la forme d'un arbre comportant : 

- une pluralite de ncEuds reprSsentant les 
phases constituant le service ; 
10 - au moins un arc oriente menant d'un noeud 

a un autre reprSsentant 1 ' enchainement en sequence de 
deux phases ; 

9. Precede selon la revendication 8, 
caracterise en ce que 1' arbre de f ormalisation comporte 

15 en outre : 

- au moins un nceud suivi de plusieurs 
arcs orientes en paralleled 

- au moins un noeud suivi de plusieurs 
arcs orientes en fonction du choix de la phase suivante 

20 dependant soit d'une condition externe au systdme, soit 
d'une condition interne liee a I'etat courant du 
systSme . 

10. Proc6dS selon I'une des revendications 1 S 
9, caracterise en ce que le modele intermediaire 

25 elabor^ comporte les flots d' execution formalisms 
caracterisant le comportement d'entites logicielles et 
leurs interactions, au moins une specification des 
ressources decrivant les materiels physiques, et au 
moins une specification d' environnement representant le 

3 0 comportement des utilisateurs . 
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